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Abstract 

A  computational  model  of  Standing  Joint  Force  Headquarters  (SJFHQ)  processes  was 
developed  using  EXTEND  simulation  software.  In  this  paper  we  describe  the  use  of  this 
modeling  and  simulation  approach  for  analyzing  time-critical  information  systems  and 
performing  trade  studies.  An  object-oriented  model  was  constructed  of  the  processes 
performed  by  SJFHQ  members  and  simulations  were  run  to  obtain  system  measures  of 
performance.  This  model  focuses  on  the  planning  processes  performed  by  SJFHQ  members 
to  support  the  Effects-Based  Planning  processes  and  the  Operational  Net  Assessment  update. 

A  complete  four-level  architecture  was  developed  that  captures  all  processes,  sub-processes, 
information  flows,  and  personnel  task  assignments.  It  includes  detailed  architectures  and  was 
based  on  US  Joint  Forces  Command  publications  and  subject-matter  expertise.  The  model 
focuses  on  pre-crisis  operations  (where  indications  and  warnings  intimate  an  impending  crisis 
for  which  an  existing  ONA  has  relevancy)  and  a  SJFHQ  that  is  integrated  with  a  Regional 
Combatant  Commander  staff.  Distributed  operations  with  organizations  outside  the  SJFHQ 
are  also  represented.  The  simulation  was  structured  to  focus  on  personnel  issues,  including 
individual  workload  levels,  multitasking  effects,  and  how  these  workload  and  personnel 
issues  affect  the  overall  time  to  perform  the  entire  SJFHQ  planning  process. 

1.  Introduction 

The  Standing  Joint  Force  Headquarters  (SJFHQ)  concept  was  introduced  at  the  Joint  Experimen¬ 
tation  Command  during  Millennium  Challenge  2000.  The  purpose  is  to  provide  a  standing 
element  that  will  provide  information  and  collaboration  support  for  Regional  Combatant 
Commanders  and/or  Joint  Task  Forces.  This  element  will  consist  of  58  people  plus  additional 
system  analysis  personnel  (initially  seven).  Responsibilities  for  the  SJFHQ  are  to  maintain  and 
provide  information  databases,  collaboration  capabilities,  and  subject-mater  experts  (SMEs)  to 
assist  in  conducting  the  Effects-Based  Planning  (EBP)  processes.  SJFHQ  personnel  provide  a 
core  of  trained  experts  who  are  essential  to  conduct  planning  using  the  new  EBP  processes. 


2 


The  SJFHQ  will  integrate  directly  with  any  regional  command  structure  established  to  manage  a 
crisis,  assist  in  using  infonnation  from  an  Operational  Net  Assessment1  (ONA)  database,  and 
participate  in  the  overall  command  planning  and  decision-making  cycle.  Implementation  of  this 
new  SJFHQ  concept  is  expected  to  greatly  enhance  a  region’s  command,  control,  communica¬ 
tions  and  intelligence  (C3I)  processes  and  crisis  management.  SJFHQ  is  a  new  concept  that  has 
not  yet  been  fully  implemented  and  personnel  are  currently  being  trained  to  occupy  these  billets. 

Detailed  information  about  this  organization’s  operation  does  not  yet  exist,  such  as  the  amount  of 
time  or  effort  involved  to  conduct  all  the  various  tasks  that  comprise  SJFHQ  responsibilities. 

The  goal  for  this  modeling  and  simulation  work  is  to  better  understand  personnel  issues,  in  terms 
of  how  many  people  are  needed  to  perform  specific  functions,  what  types  of  personnel  are 
needed,  improve  the  assignment  of  tasks  to  personnel,  and  understand  the  impact  of  workload  on 
the  time  to  complete  the  overall  EBP  process. 

Osmundson  (2002)  points  out  that  a  strength  of  systems  engineering  is  the  ability  to  analyze 
complex  systems  problems  in  terms  of  fundamental  parameters,  formulate  alternate  architectural 
solutions,  perform  trade-off  analyses  of  the  alternate  solutions,  and  select  a  best  solution  based 
on  a  reasonable  set  of  selection  criteria.  Modeling  and  simulation  of  SJFHQ  operations  provides 
an  efficient  and  cost  effective  means  to  obtain  data  to  provide  inputs  to  answer  key  questions  of 
interest  to  concept  developers.  Infonnation  developed  through  SJFHQ  implementation 
simulation  runs  can  be  used  to  examine  details  regarding  SJFHQ  processes  and  task  performance 
and  make  decisions  so  that  initial  use  of  these  units  can  be  as  efficient  as  possible. 

There  is  an  increasing  need  for  application  of  systems  engineering  principles  to  the  analysis  and 
design  of  complex,  expensive,  and  performance-critical  infonnation  systems  (Osmundson,  2002). 
A  systems  engineering  approach  was  applied  to  produce  data  that  will  help  system  developers 
make  informed  decisions.  The  goal  is  to  gain  insight  into  the  effectiveness  of  the  processes  as 
performed  by  the  designated  personnel  and  organizational  design  issues  in  a  cost-effective  manner. 

2,  Background 

The  SJFHQ  is  not  designed  as  a  standing  Joint  Task  Force  (JTF),  but  rather  as  a  standing  element 
that  focuses  on  a  Commander  in  Chiefs  (CINC)  operational  trouble  spots.  This  knowledge¬ 
centric,  cross-functional  organization  takes  advantage  of  knowledge  and  information  flow.  The 
SJFHQ  functions  at  the  operational  level  of  national  defense  as  the  joint  C2  element  to  support  a 
rapid  decisive  operation.  When  fully  operational,  this  important  and  emerging  C2  structure  will 
transform  the  preemptive  and  follow-on  options  a  unified  CINC  will  have  (U.S.  Joint  Forces 
Command,  2002).  It  will  provide  the  CINC  an  increased  range  of  options  for  crisis  response 
within  his  Area  of  Responsibility  (AOR). 

The  SJFHQ  will  provide  each  regional  CINC  an  informed  and  in-place  C2  capability.  The  goal  is 
to  have  at  least  one  operational  SJFHQ  in  each  regional  command  by  FY05.  It  is  anticipated  that 
the  SJFHQ  will  reduce  the  ad  hoc  nature  of  standing  up  today’s  JTF  Headquarters  and  provide 


'Operational  Net  Assessment  (ONA)  is  a  product  of  collaboration  among  analysts  at  strategic,  operational,  and  tactical 
levels.  The  ONA  views  a  potential  adversary  as  an  interdependent  system  of  systems,  all  of  which  contribute  to  some 
degree  toward  his  societal  coherence,  will,  and  capability  to  pursue  a  course  of  action  inimical  to  friendly  interests. 
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increased  stability  as  a  result  of  the  deep  situational  understanding  developed  prior  to  SJFHQ 
employment.  The  expectation  is  that  the  SJFHQ  will  give  the  CINCs  an  advantage  of  time, 
perhaps  the  most  critical  resource,  (ibid)  This  C2  capability  should  enable  improved  pre-crisis 
planning  on  CINC-directed  focus  areas.  For  example,  having  a  SJFHQ  should  provide  an 
enhanced  C2  capability  based  on  a  more  timely  and  improved  situational  awareness  and  an 
augmented  understanding  of  the  adversary  and  friendly  capabilities. 

It  is  expected  that  different  combatant  commanders  (COCOMs)  will  use  their  SJFHQ  element  in  a 
variety  of  ways,  and  that  SJFHQ  utilization  will  also  vary  with  the  situation.  It  will  be  some  time 
before  a  body  of  information  is  available  that  provides  the  input  needed  to  help  establish  optimal 
manning  and  utilization  of  SJFHQ.  A  methodology  to  develop  an  understanding  of  SJFHQ 
implementation  is  needed  so  that  initial  use  of  these  units  can  be  as  efficient  as  possible.  Process 
modeling  and  simulation  of  SJFHQ  operations  is  an  efficient  and  cost  effective  means  to  obtain 
data  to  provide  inputs  to  answer  key  questions  of  interest  to  concept  developers.  Simulation  runs 
can  be  used  to  examine  details  regarding  SJFHQ  processes  and  task  performance. 

The  SJFHQ  modeling  and  simulation  project,  at  Naval  Postgraduate  School  (NPS),  in  Monterey, 
CA,  in  partnership  with  Boeing,  developed  an  initial  version  of  the  simulation  and  produced 
initial  runs  and  results.  This  paper  provides  a  brief  description  of  the  steps  that  were  taken  to 
develop  the  simulation,  its  current  status,  and  discussion  of  the  way  it  can  be  used  to  make 
informed  decisions  about  structuring  the  emerging  SJFHQ.  We  also  describe  work  needed  to 
configure  the  simulation  to  produce  more  detailed  implementation  versions  and  produce 
additional  information  required  by  the  program  office. 

Naval  Postgraduate  School  supported  the  SJFHQ  program  office,  RADM  O’Hanlan,  Joint  Forces 
Command,  by  developing  an  executable  model  of  the  core  SJFHQ  processes.  A  complete  four- 
level  architecture  was  developed  that  captures  all  processes,  sub-processes,  infonnation  flows, 
and  personnel  task  assignments.  The  simulation  was  developed  using  EXTEND  simulation 
software  using  an  advanced  database  approach  in  partnership  with  Boeing  under  an  NPS-Boeing 
Cooperative  Research  and  Development  Agreement  (CRADA).  As  the  simulation  is  run, 
analyses  focus  on  personnel,  in  particular,  on  work  assignments,  the  effects  of  multi-tasking,  and 
efficiencies  in  planning  gained  by  having  the  SJFHQ  as  a  central  component  of  the  Effects- 
Based  Planning  and  Operations  processes.  Results  of  the  analyses  produced  by  the  simulation 
model  can  be  used  by  the  program  office  to  propose  and  examine  improvements  to  the  SJFHQ. 

3.  Work  Accomplished 

The  following  simulation  development  tasks  were  completed.  Tasks  are  listed  in  the  order  they 
were  accomplished  to  illustrate  the  logical  process  of  simulation  development. 

1.  Determine  all  SJFHQ  processes. 

2.  Decompose  processes  into  three  levels  of  sub-processes,  down  to  the  individual  task 
level. 

3.  Develop  an  SJFHQ  operational  architecture. 

4.  Vet  the  architecture  with  J8 9. 

5.  Identify  tasks  that  are  performed  to  accomplish  these  processes. 

6.  Determine  task  sequencing,  interdependences,  and  infonnation  flow. 

7.  Identify  the  individuals,  by  title,  who  work  on  these  tasks. 

8.  Define  task  workgroups  (all  processes  are  decomposed  to  the  task  level). 
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9.  Develop  a  methodology  and  accompanying  tables  that  map  people,  task  workgroups, 
and  processes  to  provide  the  database  foundation  for  the  simulation. 

10.  Develop  a  multi-tasking  module  that  represents  human  work  performance. 

1 1 .  Create  the  baseline  S  JFHQ  simulation. 

12.  Perform  rigorous  tests  of  the  simulation  to  insure  proper  operation  (verification). 

13.  Develop  and  report  the  results  of  simulation  runs  to  illustrate  use  of  the  methodology. 

Each  of  these  simulation  development  tasks  is  briefly  described  below.  Source  documents  for 
this  development  included:  Concept  of  Employment,  June  03,  (US  Joint  Forces  Command, 

2003)  and  Standard  Operating  Procedures,  October  03  (US  Joint  Forces  Command,  2003). 
Detailed  review  of  this  work  was  provided  by  CDR  John  Looney,  a  subject  matter  expert  (SME), 
and  a  fonner  SJFHQ  team  member. 


3.1  Determine  SJFHQ  Processes:  The  first  step  entailed  developing  an  understanding  of  the 
scope  of  the  overall  processes  performed  by  the  SJFHQ.  The  majority  of  this  information  was 
obtained  from  the  following  US  Joint  Forces  Command  reference  documents.  Concept  of 
Employment  has  chapters  describing  staff  relationships  between  the  Regional  Combatant 
Commander  (RCC)  and  SJFHQ,  staff  relationships  between  the  Joint  Task  Force  (JTF)  and 
SJFHQ,  pre-crisis  planning,  and  how  these  members  of  the  SJFHQ  collaborate  to  conduct  an 
ONA  and  EBP.  Additional  infonnation  included  in  the  Concept  of  Employment  document  is 
included  in  appendices  that  describe  the  processes  employed  for  conducting  Effects  Based 
Operations  (EBO),  Operational  Net  Assessment  (ONA),  and  other  detailed  SJFHQ  organization 
and  billet  descriptions. 


Standard  Operating  Procedures  is  a  more  extensive  document,  which  contains  six  chapters 
describing  the  activities  of  the  following  SJFHQ  sub-organizations: 

•  Command  Group 

•  Information  Superiority  Group 

•  Operations  Group 

•  Logistics  Group 

•  Planning  Group 

•  Knowledge  Management  Team 

This  publication  includes  appendices  that  describe  the  activities  of  each  sub-organization, 
including  details  on  EBP  and  ONA.  There  is  also  an  appendix  that  describes  responsibilities  of 
the  following  Boards,  Centers,  Cells,  and  Working  Groups: 

•  Joint  Information  Superiority  Cell  •  Time-Sensitive  Targets  Cell 

•  Joint  Collection  Management  Cell  •  Logistics  Coordination  Board 

•  Joint  Coordination  Board  (JCB)  •  Blue/Red  Cell 

•  JCB  Working  Group  •  Joint  Planning  Group  (at  JTF  level) 

•  Joint  Fires  Working  Group  •  Joint  Knowledge  Management  Board 


Considerable  interpretation  of  the  material  in  these  reports  was  needed  to  produce  the  process 
maps  and  tables  that  comprise  the  base  of  the  simulation.  In  many  cases  the  experience  of  the 
SME  had  to  be  used  to  provide  correct  interpretations.  The  end  result  is  a  process  mapping  that 
captures  significant  SJFHQ  EBP  process  details  and  ONA  updating  operations,  and  places  them 
in  correct  relationship  to  each  other. 
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3.2  Decompose  into  Sub-Processes:  The  simulation  tool  used  for  this  project,  EXTEND, 
allows  one  to  employ  an  object-oriented,  hierarchical  approach.  This  approach  simplifies  setting 
up  the  underlying  model.  Relatively  few  top-level  process  blocks  are  defined  that  capture  the 
major  operational  processes  undertaken.  The  six  top-level  process  blocks  for  SJFHQ  are  shown 
in  Table  1 .  Within  each  process  there  are  a  large  number  of  tasks  that  must  be  performed.  In  the 
following  section  we  describe  how  these  six  processes  are  decomposed  into  three  levels  of  sub¬ 
processes.  Each  level  of  sub-processes  contains  logical  groupings;  they  are  similar  in  function, 
they  are  performed  by  the  same  personnel,  they  address  the  same  tactical  operation,  etc.  The  end 
result  is  a  hierarchy  of  processes  and  sub-processes  that  correctly  represents  the  operation  and 
that  also  provide  the  structure  needed  for  the  model  and  simulation.  A  general  rule  for  doing  this 
type  of  decomposition  is  to  decompose  no  further  than  necessary  for  the  particular  study  being 
done.  Table  1  shows  the  processes  and  the  number  of  sub-processes  at  each  level. 

Table  1 .  SJFHQ  Top-Level  Processes  and  Number  of  Sub-Processes  for  each 

Sub-Level  within  the  Model 

Sub-Processes 


Process 

Level- 1 

Level-2 

Level- 

Command  Directives 

6 

4 

19 

Effects-Based  Planning 

4 

15 

76 

Operational  Net  Assessment 

7 

35 

235 

Collaborative  Info  Environment 

3 

3 

10 

Training/Exercises 

3 

3 

15 

Deployment/Logs/Transport 

3 

3 

22 

Level-3  is  the  task  level,  the  level  at  which  personnel  produce  infonnation.  There  are  377  of 
these  task-level  sub-processes.  The  process  table  contained  in  the  SJFHQ  Simulation  technical 
report  (Schacher,  Dailey,  Looney,  Saylor,  Jensen,  Osmundson,  Hutchins  &  Gallup,  2004) 
presents  the  details  of  this  decomposition. 

3.3  Develop  a  SJFHQ  Operational  Architecture:  The  architecture  required  for  process 
simulation  utilizes  components  from  the  Department  of  Defense  Architecture  Framework 
(DODAF)  but  requires  more  detail.  The  decomposition  referred  to  above  was  captured  in 
process  maps  that  are  presented  in  the  SJFHQ  Simulation  report.  (Due  to  space  limitations  these 
tables  cannot  be  included  here.)  These  maps  provide  an  easy  visualization  of  information  flow 
and  process  interrelationships.  Depending  on  the  simulation  technique  employed,  one  directly 
uses  architecture  maps  or  the  process  table  to  build  the  simulation.  For  the  standard  technique 
where  process  blocks  are  laid  out  on  a  visual  template  and  connections  made  between  them,  the 
maps  are  used.  For  the  database  method  reported  here,  the  tables  are  used.  Even  so,  developing 
the  maps  was  a  necessary  step  to  ensure  that  information  flow  is  correct,  logical,  and  contains 
neither  sinks  (processes  that  have  no  output)  nor  infinite  loops. 

3.4  Vet  the  Architecture  with  J-89:  J-89  has  the  mandate  to  develop  operational  architectures 
for  the  SJFHQ  and  JTF.  It  is  important  that  the  architecture  developed  for  this  project  is  in 
agreement  with  the  SJFHQ  architecture  that  is  officially  approved.  Architectures  developed  for 
this  project  go  to  a  lower  level  of  detail  than  required  by  J89,  thus  we  vetted  our  architectures 
only  at  the  top  levels. 
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3.5  Identify  Tasks:  Several  different  types  of  SJFHQ  responsibilities  were  identified  and 
tracked:  scheduled  meetings,  infonnation  production,  command  and  team  decisions,  information 
assessment,  etc.  Many  involve  sub-processes,  such  as  producing  individual,  specific  pieces  of 
information.  These  have  been  broken  down  to  individual  tasks,  to  the  level  where  one  can 
identify  the  groups  of  personnel  that  work  on  them. 

3.6  Determine  Task  Sequencing,  Interdependences,  and  Information  Flow:  Processes,  and 
their  included  tasks,  are  perfonned  in  an  order  such  that  information  is  produced  and  moves 
through  the  processes  in  the  correct  order.  Some  processes  occur  in  a  pre-determined  sequence; 
some  occur  in  parallel.  This  has  been  mapped  in  order  to  set  up  the  simulation  correctly.  Maps 
that  allow  visualization  of  this  flow  are  contained  in  Schacher,  et  al.,  2004. 

3.7  Identify  Individuals,  by  Title,  and  their  Associated  Work  Tasks:  The  purpose  of 
developing  the  simulation  is  to  track  and  measure  latencies  associated  with  personnel  activities, 
the  work  SJFHQ  members  have  on  their  desktops,  how  processing  their  tasks  is  affected  by 
multitasking,  and  so  on.  Accomplishing  this  requires  knowledge  of  the  specific  personnel  who 
are  assigned  to  each  task.  The  reference  reports  show  processes  assigned  to  major  groups  and 
also  the  personnel  within  these  groups.  For  most  cases  they  do  not  specify  personnel  information 
down  to  the  task  level.  SME  knowledge  was  required  to  specify  lower-level  tasks  and  individual 
personnel  assignments. 

3.8  Define  Task  Workgroups:  In  order  to  account  for  task  sharing  among  several  individuals,  it 
is  convenient  to  define  groups  that  are  responsible  for  carrying  out  each  task.  These  can  be,  but 
are  not  necessarily,  groups  that  are  defined  in  the  SJFHQ  documents.  There  is  some  artificiality  in 
defining  these  task  workgroups  in  that  they  are  not  necessarily  actual  operational/tactical  groups. 
They  are  a  modeling  convenience  because  they  provide  a  simple  way  to  record  personnel 
assignments  for  different  SJFHQ  configurations.  The  task  workgroups  to  which  an  individual  is 
assigned  can  be  simply  entered  into  a  table  to  produce  a  unique  configuration.  At  this  point  in  the 
project,  personnel  assignments  are  contained  in  the  master  table  presented  in  Schacher,  et  al.,  2004. 

3.9  Develop  Maps  of  People,  Task  Workgroups,  and  Processes:  Assignment  of  people  to 
task-level  sub-processes  has  been  completed.  As  noted  above,  assignment  of  workgroup  titles 
and  subsequent  association  of  these  workgroups  with  sub-processes  has  not  been  done.  This 
does  not  affect  simulation  operation.  What  is  missing  is  a  convenient  graphical  user-interface  to 
facilitate  database  manipulation  to  make  changes  to  reassign  personnel. 

3.10  Develop  a  Human  Multi-Tasking  Module:  At  the  core  of  the  simulation  is  the  ability  to 
model  an  individual  performing  tasks  under  conditions  where  he/  she  can  be  interrupted  by 
meetings  or  higher-priority  tasks,  have  several  tasks  on  their  desk  at  the  same  time,  and  need  to 
coordinate  work  with  others.  A  module  has  been  developed  to  model  these  human  perfonnance 
modalities.  The  simulation  contains  a  human  multi-tasking  module  for  each  of  the  SJFHQ 
personnel.  A  step  that  remains  to  be  done  is  assigning  individual  skill  levels.  This  will  enable 
conducting  simulation  runs  that  take  into  account  varying  skill  levels  of  SJFHQ  members. 

3.11  Create  the  Baseline  SJFHQ  Simulation:  It  is  not  possible  at  this  time  to  develop  a 
simulation  that  is  representative  of  “SJFHQ  reality”  because  such  a  reality  does  not  yet  exist. 

The  baseline  that  has  been  developed  contains  all  of  the  known  processes  and  tasks  that  are 
performed  by  the  SJFHQ  organization.  From  this  baseline,  and  the  modular  database  simulation 
configuration,  one  can  easily  reconfigure  the  SJFHQ  simulation  to  produce  a  simulation  that 
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represents  various  realities,  such  as  variations  on  SJFHQ  utilization  by  specific  Combatant 
Commanders  (COCOMs).  It  is  also  easy  to  reconfigure  the  simulation  to  do  “what-if  ’  analyses. 

3.12  Perform  Simulation  Tests:  The  SJFHQ  simulation  has  been  run  for  a  range  of  conditions 
to  test  proper  perfonnance  of  task  routing,  the  human  performance  module,  and  information 
passing  between  processes.  Conditions  have  been  set  so  that  the  work  distribution  causes 
overload  and  blocking  of  task  performance  at  task  workgroups.  Task  performance  times  have 
been  adjusted  to  test  process  synchronization  and  to  detennine  critical  process  nodes  (processes 
where  delays  will  cause  significant  disruptions  in  SJFHQ  performance). 

3.13  Develop  and  Report  Results  from  Simulation  Runs:  The  results  produced  thus  far  are 
representative  of  the  types  that  can  be  produced  and  represent  one  step  toward  simulation 
validation.  True  validation  cannot  be  done  until  field  data  is  available  from  SJFHQ  operations. 

3.14  Required  Future  Work 

The  initial  simulation  produced  is  a  baseline.  The  SJFHQ  simulation  methodology,  structure,  and 
analysis  methods  are  now  in  place.  Results  that  have  been  produced  were  obtained  to  validate 
correct  simulation  performance,  not  SJFHQ  perfonnance  in  an  operational  situation.  Additional 
work  needed  to  provide  results  that  apply  to  operational  situations  or  for  program  office  planning 
are  described  below.  We  refer  to  steps  A,  B,  and  C  below  in  defining  follow-on  work. 

Step  A.  The  baseline  simulation  has  the  following  principal  attributes:  (1)  It  contains  all 
required  EBP  and  ONA  updating  processes;  (2)  it  contains  a  methodology  for  conducting 
simulation  runs  and  analysis;  (3)  it  is  modular  so  that  rapid  reconfiguration  can  be  accomplished; 
and  (4)  it  has  been  validated  for  proper  operation. 

Step  B.  A  principal  step  in  simulation  development  is  parameterization  of  its  process 
modules/blocks.  Parameters  most  often  used  are:  (/)  processing  time,  (//)  process  capacity,  (///') 
information  input  and  output  requirements  for  initiation  and  completion,  (iv)  information  content 
and  formats,  and  (v)  conditions  such  as  mandated  schedules  and  synchronization.  Strictly 
speaking,  information  content,  fonnats,  schedules,  and  synchronization  are  not  process 
parameters,  rather  they  are  treated  as  process  interface  requirements. 

Step  C.  Simulation  results  are  produced  in  response  to  a  set  of  questions  or  requirements. 
Before  results  can  be  produced,  the  simulation  requires  the  following  infonnation:  (1)  a 
statement  of  the  question(s)  to  be  answered,  (2)  a  set  of  results  parameters  (measures)  to  be 
produced  to  answer  the  questions,  and  (3)  specification  of  the  conditions  under  which  the  results 
are  to  be  detennined.  In  order  to  quantify  data  latency  in  an  information  system  the  analysis 
technique  must  explicitly  express  the  system  in  terms  of  variables,  or  design  factors  that  can  be 
summed  to  give  an  overall  system  response  time  (Osmundson,  2000). 

The  baseline  simulation  containing  the  principal  attributes  (step  A)  is  complete.  Parameterization 
of  the  process  modules  and  blocks  (step  B)  was  accomplished  using  the  SME’s  expertise, 
however,  this  parameterization  is  not  necessarily  representative  of  an  existing  or  planned 
operational  situation.  Simulation  results  produced  in  response  to  a  set  of  questions  or 
requirements  (step  C)  remains  to  be  done.  In  the  following  section  we  begin  with  step  C  then 
proceed  to  step  B,  which  is  the  normal  method  for  study  development.  All  studies  require  that 
the  baseline  exist,  step  A,  which  has  been  accomplished. 
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Study  Definition:  We  envision  two  types  of  studies:  (1)  What-if  analyses  defined  to  meet 
Program  Office  objectives  and  (2)  determination  of  the  effectiveness  of  proposed  and  actual 
COCOM  use  of  the  SJFHQ.  For  the  first  type  of  study  the  simulation  would  be  configured  to 
match  the  what-if  situation.  For  example,  one  could  determine  the  effectiveness  of  adding 
particular  types  of  personnel  to  SJFHQ,  or  the  effectiveness  of  reconfiguring  workgroups. 

COCOMs  use-effectiveness  studies  require  a  definition  of  the  proposed  configuration.  SJFHQ 
could  be  fully  integrated,  used  as  a  stand-alone  unit,  be  responsible  for  some  decisions,  etc.  It 
may  be  that  not  all  58  people  (or  65  if  considering  System-of-System  Analysis  personnel)  would 
be  available,  and  thus  the  model’s  structure  would  be  altered  to  correspond  to  the  particular 
configuration. 

4.  SIMULATION  METHODOLOGY 

The  SJFHQ  simulation  was  developed  with  EXTEND  simulation  software,  a  highly  respected 
off-the-shelf  discrete  event  simulation  methodology  that  can  rapidly  develop  a  wide  range  of 
process  models  (http://www.imaginethatinc.com).  Boeing’s  Phantom  Works  group  has 
substantial  expertise  in  utilizing  EXTEND  simulation  software  having  developed  simulation 
analysis  tools  for  a  wide  variety  of  military  and  commercial  system  architectures.  Validated 
simulations  have  been  developed  for  several  domains,  including  network-centric  communication 
systems,  time-critical  targeting  scenarios,  and  resource/logistical  optimization. 

Models  in  EXTEND  are  structured  by  connecting  library  block  components  that  logically 
describe  the  process  or  system  that  is  modeled.  EXTEND  provides  a  library  of  validated  base- 
blocks  to  work  with  and  more  than  95%  of  the  SJFHQ  model  was  developed  with  these  standard 
components.  These  libraries  were  then  augmented  with  custom  block  components  that  were 
developed  to  model  a  number  of  unique  characteristics  of  the  SJFHQ  processes.  These 
customized  Boeing/SJFHQ  blocks  are  stored  and  delivered  in  an  EXTEND  library  file  that  is 
installed  before  launching  the  model  file. 

The  SJFHQ  model  leverages  EXTEND ’s  strong  hierarchical  capabilities,  where  base  library 
block  components  are  further  encapsulated  for  model  organization,  library  storage  and 
replication.  For  example,  each  of  the  65  personnel  in  the  SJFHQ  element  is  represented  by  a 
Person  hierarchical  block  (see  the  multiple  “P”  blocks  in  the  top-level  view,  in  figure  1).  The 
Person  h-block  is  added  from  the  customized  SJFHQ  library  and  is  made  up  of  basic  EXTEND 
library  components.  Note  that  within  this  Person  h-block  is  another  h-block  called  “Working  on 
Assignments”  which  groups  the  model  constructs  for  multi-tasking  assignments  and  prioritizing 
of  assignments  by  an  individual.  Figure  2  depicts  the  model  construct  of  a  Person  H-block. 

EXTEND  is  uniquely  powerful  in  it’s  ability  to  structure  scenario  input  data  within  it’s  own 
internal  relational  database.  For  the  SJFHQ  application,  the  simulation  database  structure  is  an 
EXTEND  replication  of  the  Excel  spreadsheet  that  specifies  infonnation  flow  between  the 
processes  and  sub-processes  (for  more  detail  on  the  EXTEND  database  see  Schacher,  et  ah, 
2004).  Database  tables  are  directly  (and  efficiently)  accessed  by  the  model  constructs  during 
run-time.  The  database  can  then  be  easily  modified  with  an  alternative  scenario  for  comparison. 

The  SJFHQ  simulation  database  is  used  to  collect  specific  customized  outputs.  As  the  primary 
objective  for  use  of  this  simulation  will  focus  on  personnel  utilization  and  time  to  complete  tasks, 
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one  of  the  principal  outputs  collected  is  personnel  work  hours  by  task.  A  plotter  for  each  team 
member  shows  the  number  of  tasks  on  their  desk  at  any  given  time  during  the  simulation 
timeline.  The  model  also  logs  each  “instance”  of  a  layer  that  has  been  initiated  by  the  model. 
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Figure  1.  Top-level  view  of  the  EXTEND  Standing  Joint  Force  Fleadquarters  Model. 
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Figure  2.  Model  Constructs,  Person  Fl-Block. 

Records  in  the  log  tables  (Focus,  Process,  Sub-Process,  Task  and  Assignment  levels)  capture 
start  time,  completion  time,  and  show  the  number  of  hours  elapsed  from  start  to  finish. 

5.  SJFHQ  PROCESSES  STRUCTURE 

5.1  Core,  Top-Level,  Processes  and  Levels  Structure 

The  six  “core”  processes  included  in  the  SJFHQ  model  and  the  three  levels  of  sub-processes 
within  each  are  depicted  in  Figure  3.  Figure  3  shows  the  sub-process  levels  under  Effects-Based 
Planning.  Under  each  of  the  sub-processes  in  Level- 1  there  are  a  number  of  Level-2  sub¬ 
processes,  with  further  decomposition  down  to  Level-3.  Sub-processes  are  indicated  by  white 
boxes.  A  logical  numbering  scheme  for  all  processes  and  sub-processes  is  used  to  track  their 
relationships,  for  example: 

3.0  Effects-Based  Planning 
3.2  Mission  Analysis 

3.2.8  Determine  End  State  Obj  ectives 

3.2. 8. 3  Develop  Recommended  Priority  Effects  List  (PEL) 

Figure  3  also  shows  a  Level-3  sub-process  sending  a  task  to  a  work-unit  (referred  to  as  boards, 
centers,  cells,  and  work  groups/units).  A  large  number  of  work-units  comprise  the  SJFHQ,  the 
composition  of  each  depending  on  the  tasks  assigned  to  them.  A  task  can  be  sent  to  a  work-unit 
only  from  a  Level-3  sub-process. 

To  some  extent  a  sense  of  time  is  indicated  in  figure  3  by  the  length  and  positions  of  the  process 
bars.  For  example,  ONA  originates  farthest  to  the  left  because  that  process  is  ongoing  almost 
continuously,  long  before  a  crisis  is  declared.  Similarly,  Logistics  and  Transportation  planning  is 
also  ongoing,  although  it  is  not  as  lengthy  a  process  as  ONA.  Command  Group  Directions  will 
initiate  all  other  processes. 
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Figure  3.  Core,  Top-Level  Processes  and  three  levels  of  Sub-Processes. 

Figure  3  also  shows  a  Level-3  sub-process  sending  a  task  to  a  work-unit  (referred  to  as  boards, 
centers,  cells,  and  work  groups/units).  A  large  number  of  work-units  comprise  the  SJFFIQ,  the 
composition  of  each  depending  on  the  tasks  assigned  to  them.  A  task  can  be  sent  to  a  work-unit 
only  from  a  Level-3  sub-process. 

To  some  extent  a  sense  of  time  is  indicated  in  figure  3  by  the  length  and  positions  of  the  process 
bars.  For  example,  ONA  originates  farthest  to  the  left  because  that  process  is  ongoing  almost 
continuously,  long  before  a  crisis  is  declared.  Similarly,  Logistics  and  Transportation  planning  is 
also  ongoing,  although  it  is  not  as  lengthy  a  process  as  ONA.  Command  Group  Directions  will 
initiate  all  other  processes. 


5.2  Sub-Process  Definitions 

A  table  in  the  SJFFIQ  Simulation  report  lists  all  sub-processes  and  their  numbers.  Table  2, 
below,  shows  a  few  rows  from  the  first  columns  in  that  table  for  explanation  purposes. 
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Table  2.  SJFHQ  Sub-Process  Definitions 


1st  2nd  3rdLvl _ Processes  and  Sub-Processes 

Command  Group  Directions 

1 . 1  Assess  National  Guidance 

1 . 1 . 1 . 1  Dummy _ 

1 .2  Assess  AOR  Plans 

1.2. 1.1  Dummy _ 

1 .3  Develop  Initial  Guidance 

1.3.1  Assess  Transition  and  Provide  Guidance 

1.3. 1.1  Dummy _ 

1.3.2  Commander's  Intent  Development 

1.3. 2.1  Develop  Commander's  Intent 

_ 1 .3.2.2  Transmit  Cdr’s  Intent  for  Mission  Analysis 


Command  Group  Directions  (1.0)  is  the  core,  or  basic  overall  process.  Develop  Initial  Guidance 
(1.3)  is  the  third  first-level  sub-process,  Commander’s  Intent  Development  (1.3.2)  its  second 
second-level  sub-process,  and  Transmit  Commander’s  Intent  for  Mission  Analysis  (1.3.2. 2)  its 
second  third-level  sub-process.  This  last  sub-process  is  at  Level-3,  which  sends  that  task  directly 
to  a  task  workgroup. 

In  reality,  tasks  can  be  sent  to  a  task  workgroup  from  any  level,  but  in  the  simulation  tasks  can  be 
sent  to  task  workgroups  only  from  the  third  sub-process  level.  Thus,  when  a  higher-level  process 
sends  a  task,  it  is  necessary  to  put  dummy  levels  in  the  simulation  so  that  the  task  is  sent  from  the 
appropriate  level.  This  is  the  reason  for  the  “Dummy”  entries.  They  have  no  effect  on 
simulation  results,  and  are  only  present  so  that  the  controlling  database  can  be  set  up  correctly. 
Table  3  includes  the  same  rows  as  shown  in  Table  2  but  shows  the  last  columns  from  the  master 
table.  (The  middle  columns  list  personnel  assigned  to  a  task  and  are  described  in  a  later  section 
of  this  report.) 

Table  3.  Example  of  Required  Input  Sources,  Task  Duration,  External  Delay,  and  Task  Priority 


Inputs  From 

Duration 

Delay 

Priority 

SECDEF 

1 

10 

RCC 

0.5 

10 

SECDEF,  3.1.1.10 

0.2 

1 

1.3. 1.1,  1.1. 1.1,  1.2.1. 1 

0.4 

5 

1. 3.2.1 

0.2 

1 

“Inputs  From”  refers  to  those  sub-processes  from  which  infonnation  must  be  received  before  the 
current  sub-processes  task  assignment  can  begin.  For  the  initial  processes  shown  here,  input 
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must  also  be  received  from  outside  the  SJFHQ  organization,  from  the  Secretary  of  Defense 
(and/or  also  the  Chainnan  of  the  Joint  Chiefs  of  Staff)  and  the  Regional  Combatant  Commander. 
Note  that  input  for  one  of  the  tasks  must  be  received  from  one  of  process  3’s  sub-processes. 

Such  interconnections  are  more  easily  seen  in  the  process  maps  discussed  below. 

Duration  is  the  estimated  amount  of  time  the  task  will  require  with  full  manning  of  the  task 
workgroup.  In  a  few  instances,  information  must  be  requested  from  an  organization  outside 
SJFHQ  before  a  task  can  be  completed.  Delay  is  the  amount  of  time  the  task  will  have  to  idle  if 
such  a  request  must  be  made. 

Priority  is  used  to  control  the  order  in  which  personnel  perform  tasks,  with  1  being  the  highest 
and  10  the  lowest  priority.  Several  priority  10  tasks  can  be  on  a  person’s  desk  at  the  same  time 
and  will  be  worked  on  in  the  order  they  arrive.  Higher  priority  tasks  will  interrupt  lower  priority 
tasks. 


5.3  Process  Architecture  Maps 

A  process  architecture  map  is  required  at  each  sub-level.  Figure  4  contains  the  first-level 
architecture  map.  Second-  and  third-level  maps  are  too  large  to  be  included  here  and  are 
presented  in  Schacher,  et  ah,  2004.  Examples  of  small  sections  of  the  lower-level  maps  are 
included  in  the  following  sections  with  explanations. 

The  first-level  map  shows  the  six  basic  processes  and  their  first-level  sub  processes.  The  arrows 
show  the  flow  of  information  from  one  sub-process  to  those  following  it  in  time.  This  figure  does 
depict  a  time  flow,  e.g.  from  top  to  bottom.  The  dashed  boxes  indicate  processes  that  occur 
outside  this  version  of  the  simulation. 

The  processes  are  not  depicted  in  numerical  order  in  figure  4  because  it  is  easier  to  depict  the 
connection  arrows  using  the  order  shown.  Figure  5  shows  a  portion  of  the  second-level  sub¬ 
processes.  In  this  figure,  the  arrows  more  accurately  represent  information  flow  than  is  seen  in 
the  first-level  diagram.  The  level  of  detail  included  in  this  Second-Level  map  is  probably  the 
best  for  visualizing  information  flow,  but  does  not  identify  the  tasks  that  consume  and  produce 
information.  Those  tasks  are  seen  in  the  third-level  map,  a  portion  of  which  is  shown  in  Figure  5. 
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Figure  4.  Basic  and  First-Level  Processes  and  Information  Flow. 
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Figure  5.  Example  of  a  Portion  of  the  Second-Level  Sub-Processes. 

Some  arrows  in  Figure  5  are  incomplete  because  they  connect  to  process  boxes  that  are  not 
included  in  this  example.  The  heavy  dashed  boxes  delineate  First-Level  sub-processes  and  show 
the  second-level  processes  included  in  each  higher-level  process. 

Figure  6  shows  a  small  portion  of  the  Third-Level  sub-process  map.  This  map  contains  no  titles, 
only  sub-process  numbers,  because  titles  would  take  up  too  much  space.  (For  example,  in  the 
second-  and  third-level  maps  take  up  three  and  five  pages,  respectively.)  Dashed  lines  are  used 
for  some  of  the  infonnation  flows  to  reduce  visual  confusion.  The  type  of  line  has  no  other 
significance.  Sub-process  blocks  that  are  in  sequence,  and  for  which  information  flows  from  one 
to  the  next  in  order  of  sequence,  are  placed  in  direct  contact  rather  than  showing  an  arrow  in 
order  to  save  space. 
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Figure  6.  Third-Level  Map  of  Standing  Joint  Force  Headquarters  Sub-Processes. 

5.3.1  Study  Results  Parameters:  The  simulation  was  set  up  to  obtain  time  measures  for  start 
and  end  times  for  all  processes  and  sub-processes  and  for  all  individuals  working  on  each  task. 
A  large  number  of  utilization  and  efficiency  studies  can  be  accomplished  with  such  output. 
Definition  of  the  questions  for  which  data  is  desired  is  needed  at  the  outset  of  a  simulation  run; 
output  tables  can  then  be  configured  to  produce  data  to  answer  the  specified  questions. 

One  could  determine  the  effect  on  product  quality  of  having  a  cutoff  time  for  tasks  (such  as 
stopping  work  on  a  product  to  meet  a  delivery  time).  In  order  to  produce  such  data  one  would 
change  task  performance  work  rules  and  also  produce  an  infonnation  quality  measure.  Such  a 
situation  is  realistic,  e.g.,  whether  the  effects  analysis  process  is  complete,  or  if  personnel  who 
perform  this  task  have  the  information  needed  to  accomplish  the  task. 

5.3.2  Study  Conditions  and  Simulation  Configuration:  A  simulation  is  configured  for  a  set 
of  conditions:  Operational  conditions,  systems  to  be  used,  number  of  personnel,  and  their 
assignments.  Changes  in  conditions  can  produce  changes  in  either  (or  both)  the  simulation 
architecture  or  parameters  included  in  the  database  tables. 
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5.3.3  Simulation  Parameters:  The  simulation  contains  several  types  of  parameters:  (1)  task 
completion  times,  (2)  personnel  work  rules,  (3)  task  priority  rules,  (4)  meeting  and  briefing 
priorities,  and  (5)  task  performance  work  rules. 

6.  PERSONNEL  TASKING 

6.1  Work  Assignments 

All  tasks  are  “sent”  to  a  group  of  defined  individuals.  The  individuals  are  identified  by  number, 
as  is  shown  in  the  following  segment  of  the  table  from  Schacher,  et  ah,  2004. 


Table  4.  Sample  of  Work  Assignments  and  Personnel  Tasking 


2.1. 1.1 

Assess  Intel,  Cdrs'  Guidance,  Geospatial  Info 

35,  36,  37,  42,  43,  46,  47,  48,  49,  50,  52,  53,  54,  55,  56, 
57,  58,  64 

2.1. 1.2 

Compare  Situation  &  Intel  with  ONA  Baseline 

50,51,52,53,54,  55,  56,57 

2.1. 1.3 

Identify  changes  in  Environment 

50,51,52,  53,54,  55,  56,57 

The  titles  of  the  numbered  individuals  are  shown  in  table  5.  Table  5  also  shows  assignments  of 
SJFHQ  personnel  to  the  Teams,  Groups,  and  Cells  as  listed  in  the  reference  documents.  This 
information,  and  SME  knowledge,  was  used  to  define  the  personnel  assignments  shown  in  the 
table. 

6.2  Assignments  to  Task  Workgroups 

Table  5  shows  the  various  organizations  and  the  people  who  are  assigned  to  them  as  defined  by 
the  reference  documents. 

Using  the  database  methodology,  the  simulation  runs  on  a  set  of  tables  that  specify  processes  and 
how  they  are  interconnected.  Task  assignments  are  defined  in  the  same  table  that  specifies  who 
works  on  each  task.  Table  5  shows  major  assignments  and  is  too  coarse  to  use  for  task  assign¬ 
ments.  A  table  was  developed  to  use  the  numbers  of  the  personnel  assigned  to  a  workgroup  as  a 
string  title  for  that  workgroup.  This  saves  a  great  deal  of  time  when  reassigning  personnel  to 
tasks.  However,  it  is  not  an  intuitive  method  for  workgroup  identification.  A  Graphical-User- 
Interface  (GUI)  that  uses  named  workgroup  identifiers,  names  that  would  be  agreed  to  by  users, 
remains  to  be  developed. 

6.3  Simulation  Human  Tasking  Module 

In  order  to  accurately  model  the  multitasking  regime  of  each  SJFHQ  team  member,  a  unique 
simulation  block  construct  was  developed  that  warrants  some  detailed  explanation.  The  modeling 
constructs  for  this  section  are  encapsulated  in  each  Person’s  h-block,  in  a  sub  h-block  called 
“Working  On  Assignments.”  As  assignment  items  are  generated  by  the  Tasks  layer  and  sent  to 
individual  team  members,  they  are  assigned  a  priority  attribute  (generally  from  1  to  15).  In 
addition,  each  individual  team  member  has  a  specific  “priority  cusp”  that  is  used  for  prioritizing 
tasks  within  an  individual’s  desktop.  A  combination  of  an  assignment’s  priority  value  and  the 
team  member’s  priority  cusp  leads  to  the  proper  routing  of  assignments  within  the  multitasking 
constructs.  This  comparison  subsequently  determines  how  an  arriving  assignment  impacts  other 
assignments  already  being  worked  on. 
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T=Team  Member 
X=Assigned 
A=Augment/Support 
C=Coordinates 
L=Assigned  Lead 
S=Secondary  Lead 

Position 


Table  5.  Personnel  Assignments  in  the  SJFHQ  Organization 

Groups  and  Teams 


o  ■« 

I 

I  s 

O  JE 


Boards,  Centers,  Cells 


O  V 


Working  Groups 


O 


>,  £ 

CQ 

o  -i 


1  Director  SJFHQ 

2  Chief  of  Staff 

3  Deputy  Chief  of  Staff 

4  Admini/Supt  Coord  #1 

5  Admin/Suprt  Coord  #2 


6  Plans  Chief 

7  Deployment  Plans  Off 

8  Ops  Law  Planner 

9  Planner  (Aerospace) 

10  Planner  (Army) _ 


L  L 
X  T 
X  T 
X  T 
X  T 


11  Planner  (USMC) 

12  Planner  (Maritime) 

13  Planner  (Space-STO) 

14  SOF  Planner 

15  Pol/Mil  Planner 


X  T 
X  T 
X  T 
X  T 
X  T 


16  Blue/Red  Planner  #1 

17  Blue/Red  Planner  #2 

18  FP  Plnr  (TBE/WME) 

19  Operations  Chief 

20  Aerosp  Ops  Off  #1 


X  T 
X  T 
X  T 


XL  TL 
X  T 


X 

L 

X  X 


X  A 
X  A 
X 
X 
X 


21  Aerosp  Ops  Off  #2 

22  Land  Ops  Officer  #1 

23  Land  Ops  Officer  #2 

24  SOF  Ops  Officer  #1 

25  SOF  Ops  Officer  #2 


X  T 
X  T 
X  T 
X  T 
X  T 


X 

X  X 
X 

X  X 
X 


26  Maritime  Ops  Off  #1 

27  Maritime  Ops  Off  #2 

28  Fires/Targeting  Off 

29  Logistics  Ops  Chief 

30  Transport  Ops  Off 


X  T 
X  T 
X  T 
T 
T 


X  X 
X 

L  X 


31  Logs  Coordinator 

32  Strat  Mobil  Plans  Off 

33  Sustain  Plans  Off 

34  Personnel  Plans  Off 

35  Info  Superiority  Chief 


X 


X  X 


36  Info  Superiority  Ops  Off 

37  Intelligence  Supervisor 

38  Intelligence  Planner 

39  ISR  Collection  Planner 

40  Current  Intel  Integrator 


L 

X 

X 

A  X 


X  X 
X  X 
X 
X 
X 


41  ISR  Operations  Officer 

42  ISR  Collection  Manager 

43  Info  Ops  Supervisor 

44  Info  Ops  Planner 

45  Info  Ops  Officer _ 


A  X 
X 

X  L 

X  X 

X  X 


AL 

A 

A 


A 

AL 

A 


X 

A  X  X 


46  PSYOP  Specialist 

47  EW  Specialist 

48  Comp  Net  Ops  Spec 

49  ONA  Supervisor 

50  ONA  Network  Analyst 


A  A  X 
X 

A  A  X 

L 

X 


A 

XL 

X 


51  ONA  Effects  Planner 

52  SoSA  Analyst  (Pol) 

53  SoSA  Analyst  (Mil) 

54  SoSA  Anal  (Econ) 

55  SoSA  Anal  (Social) 


56  SoSA  Analyst  (Info) 

57  SoSA  Anal  (Infrastr) 

58  Eff  Assess  Super 

59  Eff  Assess  Planner 

60  Knowledge  Mgt  Chief 


X 

X 

X 

XL 


X 


61  Network  Mgt  Specialist 

62  KM  Officer  (Plans) 

63  KM  Officer  (Ops) 

64  KM  Off  (Info  Superior) 

65  Jt  Network  Cntrl  Off 


X 

X 

X 

X  X 
X 
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6.3  Simulation  Human  Tasking  Module 

In  order  to  accurately  model  the  multitasking  regime  of  each  SJFHQ  team  member,  a  unique 
simulation  block  construct  was  developed  that  warrants  some  detailed  explanation.  The  modeling 
constructs  for  this  section  are  encapsulated  in  each  Person’s  h-block,  in  a  sub  h-block  called 
“Working  On  Assignments.” 

As  assignment  items  are  generated  by  the  Tasks  layer  and  sent  to  individual  team  members,  they 
are  assigned  a  priority  attribute  (generally  from  1  to  15).  In  addition,  each  individual  team 
member  has  a  specific  “priority  cusp”  that  is  used  for  prioritizing  tasks  within  an  individual’s 
desktop.  A  combination  of  an  assignment’s  priority  value  and  the  team  member’s  priority  cusp 
leads  to  the  proper  routing  of  assignments  within  the  multitasking  constructs.  This  comparison 
subsequently  detennines  how  an  arriving  assignment  impacts  other  assignments  already  being 
worked  on. 

For  multitasking  purposes,  an  arriving  assignment  is  given  one  of  three  classifications:  (1) 
Normal  Assignment,  (2)  Standard  Meeting,  or  (3)  Priority  Meeting  or  Assignment.  Within  the 
Priority  sub  h-block  of  Working  On  Assignments,  an  assignment’s  classification  is  detennined 
by  comparing  the  priority  attribute  with  the  priority  cusp.  If  the  attribute  value  has  a  higher 
priority  (lower  value)  than  the  cusp,  this  is  a  Priority  Meeting  or  Assignment.  If  it  has  a  priority 
equal  or  lower  than  the  cusp  (higher  value)  than  it  is  a  Normal  Assignment. 

A  further  comparison  is  then  made  to  determine  if  this  is  a  Standard  Meeting.  It  is  important  to 
note  that  for  this  iteration  of  the  SJFHQ  simulation  a  convention  was  adapted  for  all  team 
members  to  have  a  cusp  of  7.  A  value  of  8  was  then  adapted  for  all  assignments  that  were  to  be 
classified  as  a  Standard  Meeting.  This  priority-to-cusp  construct  is  anticipated  to  be  more  fully 
leveraged  in  later  model  versions. 


[  1 6466][7]  Working  On  Assignments 


Nor  mal  Shift  Status 
Pri  orityShift  Status 

PersonRec 


|ftssignmesy^ 


Help  IFerson21  | 


-Ml  I 


Figure  6.  Model  Constructs,  Working  On  Assignments  Sub  H-Block  (Person  H-Block). 
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6.3.1  Normal  Assignments:  Normal  assignments  are  considered  multi-tasking  equals  for 
completion  by  the  team  member.  A  standard  EXTEND  Activity,  Multiple  block  is  utilized  with 
the  “Simulate  multitasking  activity”  option  set  to  On.  The  related  Help  section  for  this  block 
provides  the  following  description  for  how  multitasking  delays  are  handled: 

When  selected,  the  processing  time  of  each  item  will  be  dynamically  changed  based  on  the 
number  of  items  in  the  Activity.  This  will  simulate  the  behavior  of  a  single,  shared  resource 
among  all  of  the  items  in  the  activity.  If  there  are  two  items  in  the  activity,  the  processing 
for  each  item  will  be  twice  as  long  as  the  dialog  indicates,  if  there  are  three  items  the 
processing  will  be  three  times  as  long  and  so  on.  This  can  be  used  to  easily  simulate  a 
single  worker  that  has  many  tasks  to  perform,  but  can  only  do  one  at  a  time 


Figure  7.  Model  Constructs,  Priority  Sub  H-Block  (Working  On  Assignments). 

6.3.2  Standard  Meetings:  Standard  Meeting  assignments  are  time-specific  assignments  that  an 
individual  would  typically  participate  in  from  their  desk  (such  as  a  on-line  collaboration).  Because 
of  this  decentralized  involvement,  Normal  multitasking  desktop  activity  can  (and  typically  does) 
continue.  From  a  model  construct  point  of  view,  the  Standard  Meeting  assignments  are  routed  to  a 
separate  EXTEND  Activity,  Multiple  block,  but  in  this  case  the  multitasking  option  is  not  selected 
so  that  involvements  start  and  end  as  scheduled.  Delay  times  in  the  Normal  Assignments  activity 
block  continue  to  progress  in  parallel  with  Standard  Meeting  Assignments. 

6.3.3  Priority  Meetings  or  Assignments:  Priority  Meetings  and  Assignments  are  handled  in  a 
third  path  of  modeling  constructs.  If  an  assignment  enters  this  area,  all  activities  in  the  Normal 
and  Standard  Meetings  area  are  set  aside  (stop  processing),  and  the  team  member  is  assumed  to 
be  completely  focused  on  the  Priority  assignment  until  completion. 

The  shutdown  of  the  Normal  and  Standard  Meeting  activity  is  accomplished  as  a  part  of  the  daily 
Shift  blocks.  If  an  item  enters  the  Priority  activity  block,  the  Shift  block  receives  a  value  greater 
than  zero  from  the  activity  length  connector  and  interprets  this  as  a  signal  to  shutdown.  The 
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Figure  8.  Normal  Assignments  (top  path)  and  Standard  Meeting  (bottom  path). 

priority  construct  can  also  accommodate  the  possibility  of  a  team  member  having  more  than  one 
priority  assignment  on  their  desk  at  a  time.  If  an  individual  is  currently  working  on  a  priority 
assignment  when  another  arrives,  a  comparison  is  made  to  the  priority  attribute  values.  The 
assignment  with  the  highest  priority  (lower  value)  will  be  focused  on  first,  with  the  arriving 
assignment  able  to  “pre-empt”  the  current  task  if  necessary.  Assignments  with  equal  priority 
values  are  handled  as  FIFO. 

7.  Results 

Simulation  results  indicate  there  are  large  differences  in  individual  workload  levels.  The  percent¬ 
age  of  time  different  personnel  devoted  to  SJFHQ  tasks  ranged  from  94%  for  the  Political/Military 
Planner  to  55%  for  the  Aerospace  Planner.  While  these  numbers  represent  approximations,  they 
do  indicate  that  adjustments  in  manning,  cross-training,  or  utilization  may  be  needed.  The 
simulation  easily  reveals  the  results  of  personnel  multi-tasking  and  associated  work  rules.  Current 
work  rules  assume  that  all  individuals  involved  with  a  task  work  the  full  duration  of  time  assigned 
to  the  task  before  it  can  be  completed.  Modifying  this  rule  will  change  simulation  perfonnance. 
This  also  translates  into  work  rules  needed  to  optimize  SJFHQ  performance  during  an  operation. 

The  simulation  takes  approximately  three  seconds  to  run  through  one  full  cycle  of  processes. 

This  simulates  260  hours  of  operational  work  time  and  6000  individual  task  assignments.  The 
database  methodology  is  highly  efficient  in  that  it  allows  one  to  use  a  set  of  rules  to  drive  the 
model  architecture  and  simulation  parameters.  Modification  to  replicate  different  real 
instantiations  of  SJFHQ  utilization  and  people  tasking  should  be  easy  to  accomplish,  including 
what-if  studies. 

8,  Conclusions 

The  lack  of  any  systems  engineering  methodology  applicable  to  perform  trade  studies  for 
complex  information  systems  has  been  a  deficiency  in  view  of  the  current  focus  on  the  power  of 
information.  There  is  an  increasing  need  for  the  application  of  systems  engineering  principles  to 
the  analysis  and  design  of  complex,  expensive,  and  performance-critical  information  systems 
(Osmundson,  2004).  Until  recently,  system  solutions  for  complex  information  systems  have 
usually  been  developed  without  extensive  trade  studies  and  without  a  solid  understanding  of 
system  sensitivities  to  design  factors  and  system  input  variations. 
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Standing  Joint  Force  Headquarters 

Background 


>  Provides  a  standing  element  that  focuses  on  a  Commander  in  Chiefs 
(CINC)  operational  trouble  spots 

•  Knowledge-centric,  cross-functional  organization  takes  advantage  of 
knowledge  and  information  flow 

•  Functions  at  the  operational  level  of  national  defense  as  the  joint  C2 
element  to  support  a  rapid  decisive  operation 

•  Provides  information  and  collaboration  support  for  Regional 
Combatant  Commanders  and /  or  Joint  Task  Forces 

>  Provide  each  regional  CINC  an  informed  and  in-place  C2  capability 

•  65  people  integrate  directly  w /  any  regional  command  structure 

•  SMEs  for  Effects-Based  Planning  and  Operations  processes 

•  Reduce  the  ad  hoc  nature  of  standing  up  today’s  JTF  Hqtrs 

•  Provide  increased  stability  as  a  result  of  the  deep  situational 
understanding  developed  prior  to  SJFHQ  employment 

•  SJFHQ  will  give  the  CINCs  an  advantage  of  time,  perhaps  the 
most  critical  resource 


6 

7 

8 

9 

10 

Plans  Chief 

Deployment  Plans  Off 

Ops  Law  Planner 

Planner  (Aerospace) 

Planner  (Army) 

X 

X 

L 

X 

X 

X 

X 

L 

T 

T 

T 

T 

11 

Planner  (USMC) 

X 

X 

T 

12 

Planner  (Maritime) 

X 

X 

X 

T 

13 

Planner  (Space-STO) 

X 

X 

T 

14 

SOF  Planner 

X 

X 

T 

15 

Pol/Mil  Planner 

X 

X 

T 

X 

16 

Blue/Red  Planner  #1 

X 

X 

T 

X 

17 

Blue/Red  Planner  #2 

X 

X 

T 

X 

18 

FP  Plnr  (TBE/WME) 

X 

X 

T 

19 

Operations  Chief 

A 

XL  TL 

20 

Aerosp  Ops  Off  #1 

X 

X  T 

21  Aerosp  Ops  Off  #2 

22  Land  Ops  Officer  #1 

23  Land  Ops  Officer  #2 

24  SOF  Ops  Officer  #1 

25  SOF  Ops  Officer  #2 

X 

X 

X 

X 

X 

X  T 

X  T 

X  T 

X  T 

X  T 

26  Maritime  Ops  Off  #1 

X 

X  T 

27  Maritime  Ops  Off  #2 

X 

x  tf. 

28  Fires/Targeting  Off 

X 

X  jjfcj 

29  Logistics  Ops  Chief 

A 

T 

S 

30  Transport  Ops  Off 

A 

T 

X 

Goal  for  Modeling  and  Simulation 


>  Gain  insight  into  personnel  issues 

•  Number  and  types  of  people  needed  to  perform  specific  functions 

•  Where  bottlenecks  occur  in  conducting  the  EBP  processes 

•  Impact  of  workload  on  time  to  complete  overall  EBP  process 

•  Use  results  to 

-  Improve  assignment  of  tasks  to  personnel 
■  hdentify  critical  nodes  where  delay  in  processes  will  cause 
disruptions  in  SJFHQ  performance 

>  SJFHQ  responsibilities  identified  and  tracked 

•  Scheduled  meetings 

•  Information  production 

•  Command  and  team  decisions 

•  Information  assessment 

>  Many  involve  sub-processes,  e.g.,  producing  specific  information 

•  Broken  down  -  individual  tasks 

•  Identify  groups  of  people  that  perform  tasks 

>  Tracked  personnel  activities,  work  on  desktop,  how  performing 
tasks  is  affected  by  multi-tasking 
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Simulation  Development  Tasks 


1.  Determine  all  SJFHQ  processes 

2.  Decompose  processes  into  three  levels  of  sub-processes,  down  to  the 
individual  task  level 

3.  Develop  an  SJFHQ  operational  architecture 

4.  Vet  the  architecture  with  J89 

5.  Identify  tasks  that  are  performed  to  accomplish  these  processes 

6.  Determine  task  sequencing,  interdependences,  and  information  flow 

7.  Identify  the  individuals,  by  title,  who  work  on  these  tasks 

8.  Define  task  workgroups  (all  processes  decomposed  to  the  task  level) 

9.  Develop  methodology  and  accompanying  tables  that  map  people,  task  work¬ 
groups,  and  processes  to  provide  the  database  foundation  for  the  simulation 

10.  Develop  a  multi-tasking  module  that  represents  human  work  performance 

11.  Create  the  baseline  SJFHQ  simulation 

12.  Perform  rigorous  tests  of  the  simulation  to  insure  proper  operation 

(verification) 

13.  Report  the  results  of  simulation  runs  to  illustrate  use  of  the  methodology 
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>  SJFHQ  sub-organizations: 

•  Command  Group 

•  Information  Superiority  Group 

•  Operations  Group 

•  Logistics  Group 

•  Planning  Group 

•  Knowledge  Management  Team 

>  Boards,  Centers,  Cells,  and  Working 

•  Joint  Information  Superiority  Cell 

•  Joint  Collection  Management  Cell 

•  Joint  Coordination  Board  (JCB) 

•  JCB  Working  Group 

•  Joint  Fires  Working  Group 


Determine  SJFHQ 
Processes 


Groups: 

•  Time-Sensitive  Targets  Cell 

•  Logistics  Coordination  Board 

•  Blue/Red  Cell 

•  Joint  Planning  Group  (at  JTF  level) 

•  Joint  Knowledge  Management  Brd 


Decompose  processes  into  three 
levels  of  sub-processes 


SJFHQ  Top-Level  Processes  and  Number  of 
Sub-Processes  for  each  Sub-Level  within  the  Model 


Sub-Processes 


Process  Level-1  Level-2  Level-3 

Command  Directives 

6 

4 

19 

Effects-Based  Planning 

4 

15 

76 

Operational  Net  Assessment 

7 

35 

235 

Collaborative  Info  Environment 

3 

3 

10 

Training  Exercises 

3 

3 

15 

Deploy  ment/Logs/T  ransport 

3 

3 

22 

Total  #  task-level  sub-processes 

377 

Develop  a  SJFHQ  Operational  Architecture 


>  Architecture  required  for  process  simulation  uses  components 
from  the  Department  of  Defense  Architecture  Framework 


•  Decomposition  EBP  process  captured  in  process  maps 

■  Provide  way  to  visualize  information  flow  and  process 
interrelationships 

•  Process  blocks  laid  out  on  a  visual  template  and 
connections  made  between  them,  when  maps  are  used 

•  Database  method  reported  here,  tables  were  used 

■  Developing  the  maps  was  a  necessary  step  to  ensure  that 
information  flow  is  correct,  logical,  and  contains  neither  sinks 
(processes  that  have  no  output)  nor  infinite  loops 


Simulation  Methodology 


>  EXTEND  simulation  software,  discrete  event  application 

•  Rapidly  develop  wide  range  of  process  models 

•  Boeing’s  Phantom  Works  group  expertise  using  EXTEND 

•  Developed  simulation  analysis  tools  for  wide  variety  military/ 
commercial  system  architectures 

>  Models  structured  by  connecting  library  block  components 

•  Logically  describe  process/system  being  modeled 

>  Library  of  validated  base  blocks 

•  >95%  SJFHQ  model  developed  with  standard  EXTEND  components 

•  Augmented  with  custom  Boeing/SJFHQ  block  components 

■  Model  unique  characteristics  of  SJFHQ  scenario 

■  Stored  and  delivered  in  EXTEND  library  file  -  installed  before 
launching  model  file 

>  Leverages  EXTEND’s  strong  hierarchical  capabilities 

•  Powerful  ability  to  structure  scenario  input  data  within  its  own  internal 
relational  database 


Top-level  view  of  the  EXTEND  Standing  Joint  Force 

Headquarters  Model 


Model  Constructs,  Person  H-Block 


[26877]  Person  2 


Core,  Top-Level  Processes  and  three 

levels  of  Sub-Processes 


SJFHQ  Sub-Process  Definitions 


1st  2nd  3rd  Level  Processes  and  Sub-Processes 

1.0  Command  Group  Directives 

1.1  Assess  National  Guidance 

1.1. 1.1  Dummy 

1.2  Assess  AOR  Plans 

1.2. 1.1  Dummy 

1.3  Develop  Initial  Guidance 

1.3.1  Assess  Transition  and  Provide  Guidance 

1.3. 1.1  Dummy 

1.3.2  Commander’s  Intent  Development 

1. 3.2.1  Develop  Commander’s  Intent 

1 .3.2.2  Transmit  Cdr’s  Intent  for  Mission  Analysis 


Example  of  Required  Input  Sources,  Task  Duration, 

External  Delay,  and  Task  Priority 


Inputs  From 

Duration 

Delay 

Priority 

SECDEF 

i 

10 

RCC 

0.5 

10 

SECDEF,  3.1.1.10  1.3.1. 1, 

0.2 

1 

1.1. 1.1,  1.2.1. 1 

0.4 

5 

1. 3.2.1 

0.2 

1 

PERSONNEL  TASKING 
Sample  of  Work  Assignments 


2.1. 1.1 

Assess  Intel,  Cdr’s  Guidance, 
Geospatial  Info 

35,  36,  37,  42,  43, 

46,  47,  48,  49, ...55, 
56,  57,  58,  64 

2.1. 1.2 

Compare  Situation  &  Intel 
with  ONA  Baseline 

50,  51,  52,  53,  54, 

55,  56,  57 

2.1. 1.3 

Identify  Changes  in 
Environment 

50,  51,  52,  53,54,  55, 
56,  57 

Normal  Assignments  (top  path)  and 
Standard  Meeting  (bottom  path) 
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Results  and  Conclusions 


>  M&S  provides  an  efficient  and  cost  effective  means  to  obtain  data  to 
provide  inputs  to  answer  key  questions  of  interest  to  concept  developers 

>  Information  can  be  used  to  examine  details  regarding  SJFHQ  processes 
and  task  performance  and  make  decisions  so  that  initial  use  of  these 
units  can  be  as  efficient  as  possible 

>  Total  Simulation  run  time  — 3  seconds 

•  260  Total  work  hours 

>  Large  variations  in  personnel  use 

•  Pol/Mil  Planner  246  tasks  worked  94%  of  time 

•  Aerospace  Ops  Off  r  #1  66  29% 

•  Aerospace  Ops  Off  r  #2  14  5% 

>  Possible  solutions  to  workload  inequities 

•  Modify  number  of  personnel  types  assigned 

•  Cross  train  so  people  can  perform  a  wider  range  of  tasks 


